Skip to content

Conversation

@JSCU-CNI
Copy link
Contributor

@JSCU-CNI JSCU-CNI commented Jan 8, 2026

#1106 seems to have broken default DirLoader behavior. This PR attempts to fix that.

$ tree foo
foo
└── test dir
    ├── another test dir
    └── file.txt
# before
$ target-shell dir://foo
2026-01-08T14:46:56.840760Z [error    ] dir://foo: Failed to load target with loader DirLoader('foo') [dissect.target.target]
2026-01-08T14:46:56.840922Z [error    ] Error opening shell: Failed to find any loader for targets: ['dir://foo'] [dissect.target.tools.shell]
$ 

# after
$ target-shell dir://foo
2026-01-08T14:46:11.536849Z [warning  ] <Target foo>: Failed to find OS plugin, falling back to default [dissect.target.target]
foo:/$ 

Also DirLoader detection seems broken (target-shell foo does not work), but that might be intentional?

@Schamper
Copy link
Member

Schamper commented Jan 8, 2026

This doesn't seem to work pre-#1106 either, because your sample directory does not have a valid OS structure. I think the changes to Target.open (#1265) now skip the detection when you use URI patterns.

Even if you skip the detection, the "issue" is that find_entry_path will return None because of the aforementioned issue that the directory does not have any OS structure to it. I guess the intended change is to allow usage of the directory loader on arbitrary directories if you specify the URI?

Also DirLoader detection seems broken (target-shell foo does not work), but that might be intentional?

That's intentional, it should only work on directories that have a valid OS structure. Otherwise we can't safely/sanely do the directory iteration in Target.open_all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants